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(54) Method and system for discovering computer network InformatiCHi from a remote device 



(57) The present Invention is a method, apparatus 
and computer program product tor discovering the 
nodes and other network information of a conputer net- 
work (the target network) from a devtee or node that is 
not part of the target network (the discovery node) when 
the dtsoGvery rKxie uses a different network protocol 
than the target network. The invention involves identify* 
ing one or more adcfilional nodes (t^ke target nodes] that 
have access to network information atxxit the target 
network and with whom the discovery node can com- 
nrkunicate. This target network irrfbrn^tion can irtdude 
the identif»catk)n of nodes which are present on the net- 
work the topology of the network, the servrces provided 
by the network or by the nodes on the network, status 
informatkm as the network changes such as information 
atxxjt network and node events or alarms, eta The dis- 
covery node may also have stored information on the 
tvpes of nodes, services, and other Information vt^ch 
may be found on a network using the r>etwork protocol 
of the target network The discovery node can use the 
target nodes to receive target network information in 
various ways, inducing requesting information from a 
target node, Invoking target network functionality at a 
target node or target networic node to identify target net- 
work infonnalion. and accesstng target network infor- 
mation prevk>u8)y stored at a target Po6e or target 
network node. After recoving target network infonna* 
tion, the discovery node nrxxlels it using software 
objects that are aeated by the discovery node. These 
software objects are cfiscovery node representations of 
target network nodes and objects. The cfiscovery node 
nnakes the created ot>|ects available as representations 
of the netM>rk infornuitksn from the target network, and 



can maintain the accuracy of the represented target net- 
work information over time. 
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Descrfptioh 

BACKGROUND OF THE IWVEWTIOM 

The present invention relate generally to the field 
of connpirter network conrurtunication and nrwre particu- 
larly to the management of multiple computer networks 
enploying different network protocols. 

Computer networks allow multiple computers, 
peripherals and other information storage, retrieval or 
processing devices to share data. Each device attached 
to a network is typically referred to as a node on the net- 
work, or a node that is part of the network. If a physcal 
connection exists from a first node to a second node, 
then the second node is said to be accessible to the first 
node. If the first node is atDle to send data to the second 
node, then the first node is said to be able to contact the 
second node, and the second node is contactable from 
the first node. H the first node is further able to store 
data with the second node such that the second node 
can understand the data, then thef irst node is said to be 
able to communicate with the secorxJ node. 

Thus, in order for two nodes to be able to communi- 
cate, a physical connection between the nodes must 
first exist. The physical connection between the nodes 
can be Implemented using vartous media, including 
cables or wireless communication, and can use various 
types of signals, including electrical voltages, optical, 
radio waves, etc. In order for two nodes to comnuinicate 
and share data, the nodes must use the same network 
protocol, or have an intermediary translate between dis- 
parate protocols. A network protocol provides the mech- 
anisms that allow communication between nodes to 
take place, including directing the oommunicatal cteita 
to the correct destination, provWing enror-checWng so 
that the data arrives intact, and provkiing standard for- 
matting for communicated data so that a destinatfon 
node can understand the data. To fadlrtate communica- 
tion, a network protocol will typically use a lower-level 
data-link protocol, which serves to control the actual 
flow of data between two nodes. Various network proto- 
cols have been developed, including Transmission Con- 
trol Protocol (TCP). Internet Protocol (IP). Interr^et 
Packet Exchange (IPX), Systems Network Architecture 
(SNA). Datagram Delivery Protocol (DDP). etc. Vartous 
data-link protocols have also been devdoped, including 
Ethernet Token Ring. Rber Distrtouted Data Interlace 
(FDDI), etc. 

Ail the nodes attached to a particular physical com- 
fTKjnication medium, such as a specific coaxial cal^e. 
win typically use the same network protocol, and for a 
network protocol named XYZ, those nodes and media 
would fc)e referred to as an XYZ protocol network or 
merely an XYZ network. If a physical comnujnication 
medium included nodes that used multiple network pro- 
tocols, only those nodes using the same network proto- 
col would be referred to as a network. For example, if a 
coaxial cable had multipie nodes attached to it, with 
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some nodes using the XYZ network protocol and other 
nodes using the TUV network protocol, the nodes using 
the XYZ network protocol would be referred to as an 
XYZ network and the nodes using the TUV network pro- 
5 tocol would be refen-ed to as a TUV network. Network 
protocols are the t>asis of the logical grouping of nodes 
into networks because nodes using the sanrie network 
protocol can communicate and share data, while two 
nodes that are physically connected but use diffe-ent 
w network protocols typically cannot communicate arwj 
share data. As menttoned atove, a network protocol 
provides standard formatting for communicated data so 
that a destination node can understand the data it 
receives. Since differ era network protocols typically use 
J 5 different standard formatting, a rwde using one network 
protocol would not urxjerstand the formatting of commu- 
nicated data from a ixide using a different network pro* 
tocol. Many network protocote package the data to be 
transferred into discrete packets that move across the 
networ1<. and use a define packet structure so that the 
receiving node can unpackage and thereby understand 
the information in a data pack^. Even if two different 
network protocols both use data packets for comnuini- 
catton, they typically will use different packet struc- 
tures—thus, even if a node receives a packet from a 
node using another network protocol, the receiving 
node will not be able to unpackage the information in 
the data packet to enable the sharing of the data. 

As communication between computers has 
become increasingly pervasive and irrportanl. the 
number and size of conputer networks have con^e- 
spondingly increased, tf a particular node on a network 
is aware of the presence of another node on the net- 
work, then typically tfie network prolocd common to the 
nodes will make comnujnication possible from the first 
node to the second node. However, if the presence of a 
node on the network is not known, it typically will rrol be 
contactable. ©/en if the nodes share a physical connec- 
tion and common network protocol. It is often difficult for 
a node to discover, i.e. ascertain, the other nodes that 
are part of the network. This problem is exacertjated by 
the Increasing size of networks, by networks with nodes 
that are physically remote from other nodes, and by the 
dynamic nature of computer networks whereby new 
nodes can be purposefully added or removed at any 
time and problems with physical connections or the 
nodes themselves will commonly cause unexpected 
renrvjval of r>odes from the network. Nonetheless, some 
existing systems have been implemented whfch can 
discover the other nodes that are part of a network if all 
of the nodes use the same network protocol. 

Not only does this protiem of discovering the pres- 
ence and status of other nodes on the network inrpact 
the average user at a rrode, who may not be aware of 
which other computers are contactable for contmunica- 
tion. but it is a significant problem lor those whose job 
includes the task of managing a network of conrputere. 
The nanager must be able to determine what nodes are 
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access^e and oontactable so that network problems 
such as lack of connectivity are recognized. Moreover, 
the management of a network typically includes not only 
m^ntatning the connections t>etween nodes, txrt also 
providing specialized computer services such as file 5 
services, print services^ network security services, 
workgroup productivity services, ^c. Typically, these 
services are available to multiple nodes on the networK 
and are referred to as network services. It is crucial for 
a conputer network manager to t>e able to assess the w 
status of an of the network nodes, many of which may 
not be physically present at the location of the manager. 
Status infbnnation can be reflected In network and node 
events, including alarms. Ideally, a manager will have 
the additional ability to alter the status of one or more 15 
nodes from the manager's location, including respond- 
ing to alarms and other problems. 

In addition to the growth in size of individual compu- 
ter networks, they are increasingly becoming intercon- 
nected. One m^od of connecting two or more 20 
networks involves the existence of at least one common 
node which is on. and part of. both networks. In this sit- 
uation, nodes which are comnx>n to more than one net- 
work may serve as routers, bridges or gateways, 
passing data between the networks and thus enabling a 25 
node on one network to communicate with a node on 
another network. While each network wBI only use a 
particular network protocol, the various networks in a 
group of interconnected networks may use heterogene- 
ous network protocols. If two networks use different net- 30 
work protocols, a common node nnay also have the task 
of converting data from the protocol format of one net- 
work to the protocol format of the other. 

A common situation involves interconnected net- 
works in which both the IP network protocol and the IPX 55 
network protocol are in use by individual networks. IP, 
as part of TCP/IP. has evolved into the most pervasive 
protocol in use on the Internet. While IP historically was 
used prin^rily by high-end workstations, it is designed 
to be hardware independent and has been implemented 40 
for a wide variety of devices. IPX is part of the Net- 
Ware® protocol that was developed by Novell. Inc.. and 
was traditionally used by personal computers (PCs) 
based on Intel® 80X86 chips. As such, IPX became the 
most prevalent network protocol among networte of 45 
Intel-based PCs. As the technical cfistinctions between 
different types of computers continue to blur, it has 
become increasingly common to have interconnected 
computers of various different types, and thus it is com- 
mon to have interconnected networks in which both the so 
IP protocol and the IPX protocol are in use Additionally, 
kxjth IPX and IP have been implemented on top of mul- 
tiple data-lirri( protocols, such as Ettwrnet and Token 
Ring. While both tP and IPX route packets of data, their 
packet structures are different, and thus an IP packet 55 
woukJ not be understood by a receiving node using IPX, 
nor would an IPX packet be understood by a receiving 
node using IP. Due to these differences, the IP end IPX 



protocols are not compatible. 

The enstence of interconnected networks, particu- 
larly when the networte use different network protocols, 
only inaeases the difficutty of ascertaining the pres- 
er»ce and status of other nodes with which a particular 
node can communicate. For instance, a node on an IP 
protocol network, refen^ed to as an IP node, can typi- 
cally discover information about many contactat)te IP 
nodes by uang standard IP discovery mechanisms 
such as Packet Internet Groper (PING) (checks if a 
known node is contadable on the network). Address 
Resolution Protocol (ARP) (request a translation, often 
from another node, from the unique logical address of a 
known node to a physical address). Reverse Address 
Resolution Protocol (RARP) (request a translation, 
often from another node, from the physical address of a 
known node, often itself, to its unique logical address), 
routing tables (a node otTtains addresses of other nodes 
from destination information in transmitted messages 
that have passed by or through it), etc. An IPX node, 
which is a node on an IPX protocol network, can also 
typically dscover Infomation about other contadable 
IPX nodes by using standard IPX discovery mecha- 
nisms such as Echo (checks if a known node is oon- 
tactable on the network). Service Advertising Protocol 
(SAP) (allows IPX nodes to advertise their services to 
other IPX nodes), etc. Howeyrer, IP protocol-specific dis- 
covery mechanisnrrs do not work on an IPX protocol net- 
work because the IPX protocols and IP protocols are 
not compatible. Even if an IPX node is given access to a 
database of network information for its IPX protocol net- 
work, a node that is only on an IP protocol network may 
not be able to discover this information due to the differ- 
ences in protocols. Note that while access to ffiforma- 
tion may occur from another node on a network, access 
to information is distinct from the physical accessibility 
of one node to another on networks. Ideally, a node on 
one network should be atsle to ascertain not only the 
other nodes with which It can commurvcate, wherever 
they may be located, but also the topology of the nodes, 
arry services provided by nodes or networks, and other 
status information available from any of the intercon- 
nected networks and their nodes. Unfortunately, there is 
no general solution at this time to the problem of ascer- 
taining the presence arxi status of other nodes w'rth 
which a particular rtode can connmunicate or the net- 
work information for other networks, when there are 
interconnected networks which use drfferent network 
protocols. 

SUMMARY OF THE INVENTION 

The present invention is a method, apparatus and 
computer prograin product for discovering the nodes 
and other network informatton of a con|5uter network 
(the target network) from a device or node that is not 
part of the target network (the discovery node), particu- 
larly when the discovery node uses a different network 
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protocol than the target network. The invention involves 
identifying one or more additional nodes (the target 
nodes) that have access to netvuork informafion about 
the target network and with whom me discovery node 
can communicata The discovery node uses these tar- 
get nodes to receive target network infomfwtion, and 
models t^t information using software objects that are 
created by the discovery node. Finally, the discovery 
node nrnakes the created objects available as represen- 
tations of the network Information from the target net- 
work, and can maintain the accuracy of the represented 
target network information over time. 

The receipt of target network Information can occur 
in several different ways. In the preferred embodiment of 
the irvention, the discovery node contacts a target node 
and requests specific information about the target net- 
work from the target node. In another embodiment, the 
discovery node can use its knowledge of tte presence 
of a target node, combined with stored information spe- 
cific to the network protocol of the target network, to dis- 
cover network intormation accessible from the target 
node about the target network vwthoul requesting the 
infornDatk>n from the target node. 

The discovered target network information can 
include the identification of nodes which are present on 
the network the topology of the network, the services 
provided by the nebwork or by the nodes on the network, 
status information as the network changes such as 
information at)0ut events or alarms, eta The discovery 
node also holds stored information on the types of 
nodes, services, and other information which may be 
found on a network using the network protocol of the 
target network When the target network information is 
received, it is modeled by the discovery node using tog- 
ical abstractions based on the stored type intormaton. 
The logical abstractions are objects created by the dis- 
covery node that may con^espond to one or more physi- 
cal or logical entities on the target network. The objects 
share a common tormat vwth created objects which rep- 
resent network infbrnr^ition for networks with the same 
network protocol as the discovery node, and the com- 
mon format allows the objects to interoperBte. However, 
the format of the objects created for the target network 
irrformation is also spedfk: to ttie network protocol of the 
target network, and thus can be used to indicate that the 
network informatfon is from a network remote from the 
discovery node. Rnally the created objects are stored 
so that the discovery node can access the objects and 
their object information. 

After the network informafion is received and mod- 
eled, it can be displayed to a user at the discovery node 
or made accessible to applicatk>n programs and other 
nodes contactatsle from the discovery node. The infor- 
mation that made available corresponds to the loc^cal 
abstractions of the created objects, rather than the enti- 
ties on the target network Moreover, the discovery 
node can also request or discover additional informatbn 
in such a manner that the action occurs automatically 



under specified conditions, which allows the discovery 
node to remain apprised of any changes in network 
infomwtion on the targ^ network. This network informa- 
tion discovery process can occur for as mahy networte 

5 as are part of the interconnected group of networks or 
as. many target nodes that are identified. TTie network 
information from all of the discovered networks can be 
combined to represent all of the nodes, services, and 
other information wtilch are availat>te to the discovery 

10 node, 

BRIEF DESCRIPTION OF THE DRAWINGS 

The Greets, features and advantages of the 
15 present invention will be made apparent in the following 
detailed description in which: 

Rg. 1 illustrates a physical diagram of a typical 
interconnected computer network in accordance 
20 with the present invention. 

Fig. 2 illustrates a logical diagram showing four 
interconnected networks of computers, where two 
of the networks are using an IP network protocol 
25 and tww Of the networks are using an IPX network 
protocol. 

Rg. 3 Blustrates the portions of the interconnected 
networks of Fig. 2 which are detectable from Node 
30 1 under prior art systems. 

Rg. 4 illustrates logical communication exchanges 
for discovery of IPX protocol networks from a node 
on an IP protocol network 

35 

Rg. 5 illustrates a detailed block diagram of one of 
the nodes on an IP protocol network in the system 
of Rg. 1. 

40 Rg. 6 Illustrates a flow diagram for the Discover IPX 
Network Information From IP Network process in 
accordance wtth the present invention. 

Rg. 7 illustrates a flow diagram for the Schedule 
45 Discovery Action process in accordance with the 
present inventioa 

Rg. B illustrates a fk)w diagram for the Execute 
Scheduled Discovery Action process in accordance 
so with the present invention. 

Rg. 9 illustrates a flow diagram lor the Receive 
Requested Data From Node process in accordance 
with the present invention. 

Rg. 10 illustrates a flow da^m for the Read A 
Transactkjn From Stored Data process in accord- 
ance with the present invention. 
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Rg. 11 illustrates a flow dagram for the Model 
Transaction Infomiation With SunNet™ Manager 
(SNM) Objects process in accordance with the 
present invention. 

DETAILED DESCRIPTION OF THE INVENTION 

A method, apparatus, and computer program prod- 
uct are described for discovering the nodes and other 
network information of a computer network (the target 
network) from a device or node that Is not part of the tar- 
get network (the discovery node), particularly when the 
discovery node uses a different network protocol than 
the target network. The discovery of the network Infor- 
mation involves one or more adcfitional nodes (target 
nodes) that have access to network information about 
the target network, and with wtiom the discovery node 
can corrununicate. 

The preferred embodiment has several features, 
including the following: the discovery node is also part 
of a networK referred to as the discovery network, and 
the target network and discovery network are part of the 
same interconnected group of networks; the target node 
uses both the network protocol of the target network 
and the netwwork protocol of the discovery node; the tar- 
get node is part of at least two networks, with one of 
these networks using the target network protocol and 
another of these networks using frie discovery node 
protocol-— in the simplest example, the target node is 
part of both the discovery network and the target net- 
work; communication between the discovery node and 
target node occurs over the discovery network, and over 
other networks in the interconnected group if neces- 
sary; and the target node provides a network manage- 
ment information service that si^splies target network 
information upon request. Those skilled in the art wiD 
appreciate thai alternate emt>odiments can be obtained 
by varying one or more of these feature— lor example, 
the discovery node couW obtain the target network 
information without requesting the infonretion from a 
network management information service at a target 
node. In addition, spedfic alternate errtxxJiments wiH 
be descrSjed throughout the description below. 

Throughout this detailed description, numerous 
specific details are also set forth such as spedfte net- 
work protocols and specific mecharvsms to gather, 
receive and distrtoute network information- Those of 
ordinary skill in the art will appreciate that the present 
invention nnay be practiced without such specific details. 
In particular, the example embodiment illustrated in 
Rgs. 1-11 describes fte cfisoovery of network informa- 
tion for a target IPX network from a discovery IP 
node— however, the present invention is rK>t limited to 
the details used in the example entx)diment such as 
networks using the IP and IPX network protocols, and 
functionalities or formats provided by tvletWare compo- 
nents from Novell. Inc. (such as NXIS) a SunNet Man- 
ager components from Sun Microsystems (such as 
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SNM). 

Thus, wtiile the present invention will be discussed 
in relation to the interconnected conputer networit of 
Rg. 1, those skilled in the art will appreciate that the 
present inventk)n is not limited to the physical con- 
straints of the illustrated network: the target node and 
cfiscqvery ndde do not have to be part of the same net- 
work, or even part of the same interconnected network; 
the target node does not have to be part of the target 
network; the network protocols in use do not have to be 
IP and IPX, nor is an interconnected group of networte 
limited to two network protocols; the components are 
not limited to services or functionality from NetWare or 
SunNet Manager ; the target node does not have to have 
a network management information service; etc. 

Rgure 1 shows a physical linkage diagram of a typ- 
ical interconnected computer network which may incor- 
porate the present invention. The illustrated 
interconnected computer network includes five network 
nodes 110, 120. 130. 140 and 170 and three computer 
networks 150. 180 and 180. Network nodes 110, 120. 
130 and 1 70 are nodes that comprise the network 1 50, 
which uses fr»e IP network protocol. Network nodes 130 
and 140 are nodes that comprise the network 160, 
which uses the IPX network protocol. Network node 170 
is a node that comprises the network 180, which uses 
the IP network protocol. Those skilled in the art will 
appreciate that additional nodes and networks are pos- 
sible, and that the computer networks may be imple- 
mented using a variety of pftysica! media. Networks 
such as 180 that use the IP network protocol are 
refen-ed to as IP networks. Networks such as 160 that 
use the IPX network protocol are referred to as IPX net- 
works. In Rg. 1 , Node 1 10 is illustrated as an example 
of a discovery node, network 150 is illustrated as an 
example of a discovery network, network 160 is illus- 
frated as an example of a target networK and node 130 
is illustrated as a target node. 

Each network node is shown as a general purpose 
computer. Node 110 illustrates the six basic node oom- 
ponents which each Illustrated node contains: an input 
device ill, adisplay 112. a CPU 113. a mass storage 
114. an internal bus 115, and a main memory 115. 
Those skilled in the art will appreciate that a node on a 
network may contain variations of these components, 
including more or less components. For example, a 
printer node may consist of only a CPU and a display, 
where the display is the printed output AKemately, a 
node may contain additional components such as sec- 
ondary memory or a conrununicatfons device such as a 
modem. In addition, multiple instantiations of each com- 
ponent type may be present in a network node. For 
example, a network node may contain muftiple CPUs, 
rnultiple input devices inducfing a keytx>^ a mouse, 
and a scanner, and mutttple types of 'hnass storage 
including a hard drive, a floppy drive, a Digital Video 
Disk (DVD), a CD-Recordable device, a magneto-opti- 
cal drive, etc. A network node may also have mdliple 
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internal buses, some of which may possess slots for 
removable bus cards which provide various functional- 
ity. The otfier four inustrated nodes also consist of the 
six basic described node components, and nodes 120. 
140 and 170 will not be descrft^ed in deal here. Those 5 
skifled in the art wOl appreciate that while only the main 
memorys, such as main memory 116. are shown 
exchanging data with ttie networks, sucti as IP network 
150, other components in a network node, such as 
mass storage 114, may exchange data directly with a jo 
network without the intervention of main memory. 

In discovery node 110. the main memory 118 is 
illustrated having various main memory components 
such as a SunNet Manager console 101, an IPX dis- 
cover 1 02, an IP discover 103 and an IP network prolo- is 
col layer 104. The IP network protocol layer 104 allovre 
the node 1 10 to use the IP network protocol to commu- 
nicate with other nodes which use the IP network proto- 
col, such as nodes on IP netwofk 150 and IP network 
180, Each node which can communicate with other 20 
nodes will typlcafly have at least one network protocol 
layer. The IP discover 103 provides a mechanism for 
discovering network information about networks using 
the IP network protocol. The IPX discover 102 provides 
a mechanism for discovering network information about 2S 
networks using the IPX network protocol. As illustrated 
in the main memory 116, additional discover mecha- 
nisms can be present that vrauld discover network infor- 
mation about networks using other network protocols. 
The SunNet Manager console 101 receives network 30 
information from all of the discover mechanisms, and 
can make this information availalDle to other compo- 
nents or other nodes. Those skilled in the art will appre- 
ciate that the netvrark information couW be displayed to 
a user, transmitted to an application program on node 35 
1 10 or on another node, stored in mass storage 1 14 or 
other mass storage, including a database (not shown), 
etc. As described earlier, various mechanisms exist to 
perform the IP discover functionality from an IP network 
node, such as PIlNKa. ARP, RARP. routing tables, etc. 4o 

In target node 130, the main memory 136 is Illus- 
trated having an IP network protocol layer 137. an IPX 
network protocol layer 138, a NetWare service A 181. a 
NetWare service B 182 and a NetWare Management 
System™ export import service 139. the IP network 4s 
protocol layer 137 allows the node 1 30 to use the IP net- 
work protocol to communicate with other nodes which 
use the IP network protocol, such as nodes on IP net- 
work 150 and IP network 180. The IPX network protocol 
layer 138 alfows the node 130 to use the IPX network so 
protocol to communicate with other nodes which use 
the IPX netwvork protocol, such as nodes on IPX net- 
work 160. The NetWare sen^ice A 181 communicates 
with the IP network protocol layer 1 37 to provWe a net- 
work sen/foe A to nodes using the IP protocol. While s$ 
communication between components on the same 
node typically involves sharing data, a network protocol 
is not typically necessary for this type of inter-conrpo- 



nent communication. The NetWare senrice B 182 com- 
municates with the IPX network protocol layer 138 to 
provide a network service B to nodes using the IPX pro- 
tocoL Those skilled in the art will appreciate that nrujlti- 
pie network services may be made available by a node 
to a given network, and that ttie network services made 
availatrfe are not limited to NetWare sen/ices. 

The NetWare Management System export inport 
service 139. referred to as an NXIS. is an exanple of a 
network management information service for IPX net- 
works that can provide available network information 
upon request. IPX network information can be received 
by the IPX network protocol layer 138 at node 130, and 
this IPX network information could be entered directly 
into mass storage 134 via internal bus 135. NXIS 139 
can communfoate with either mass storage 134 via 
internal txjs 1 35 or the IPX network protocol layer 1 38 to 
access IPX network information, and can make this IPX 
network informatfon available to IPX discover 102 using 
IP network protocol layer 137 and IP network 150. The 
network infomnation can include the kJentrTication of 
nodes which are part of the network, the topology of the 
network, the services provided by the network or by the 
nodes on the network, status Biformation as the network 
changes including information about events or alarms, 
ete. 

In Fig. 2, a functional topology of the interconnected 
computer network of Fig. 1 is illustrated. It shojld be 
noted that the interconnected network illustrated in Rg. 
2 includes the nodes and networks illustrated in Fig. 1. 
txjt is not Omited to those nodes and networks. Fig. 2 
illustrates twelve nodes 110, 120, 130. 140, 170, 202. 
209. 212, 214. 224, 232, and 234 and four computer 
networks 150, 160. 180 and 235. Network nodes 209. 
232 and 234 are nodes that comprise the network 235. 
whk;h uses the IPX network protocol. Network nodes 
110, 120, 130. 170. 202. and 209 are nodes that com- 
prise the network 150. which uses the IP network proto- 
col. Network nodes 170. 212. 214, and 224 are nodes 
that comprise the network 180, which uses the IP net- 
work protocol. Network nodes 130, 140 and 224 are 
nodes that corrprise the network 160, which uses the 
IPX network protocol. It shouW also be noted that no 
particular network topology is required: networks 150 
and 235 have a bus topology, while networks 160 and 
180 have a ring topology. Those skilled in the art will 
appreciate that other network topologies may also be 
used. Node 130 provides NetWare service A 181 and 
NetWare sen/ice B 182. Node 234 provWes network 
service C 236. 

Rg. 3 illustrates the functional topology of the Inter- 
connected computer network of Fig. 2 that would typi- 
cally be discoverable by discwery node 1 1 0 under prior 
art systems. Nodes 120, 130, 1 70. 202 and 209 that are 
part of network 150, and nodes 212. 214 and ^4 that 
are part of network 180 woukJ be discoverable from 
node 110 because networks 150 and 180 use the IP 
network protocol, which is also in use by node 110. 
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While NetWare service A 181 may be discoverable b/ 
node 110 in a prior art ^tem because service A is 
made available to nodes on IP networks, NetWare serv* 
ice B 182 would ho) typically be discoverable by node 
110 in a prior art system because service B is made s 
available only to nodes on IPX netvvorks. In addition, 
nodes 140. 232 and 234 wO) typicaHy not be discovera- 
ble from node 1 10 in a prior art system because these 
nodes are not part of networks that use the IP network 
protocol, which is in use by node 110. Finally, while w 
node 224 was discoverable because it was part of IP 
network 180, the fact that node 224 is also part of IPX 
network 160 and thus directly connected to node 130 
will typically not t>e discoverable. 

Those skilled in the art will appreciate that an undis- is 
coverable network node on an IPX networK such as 
node 140. could additionally be part of another IP net- 
work not shown in Fig. 2 or Rg. 3. This additional IP net- 
work woukJ presumatily included additk>nai nodes 
which are also not shown in Rg. 2 or Fig. 3. The only 20 
physical connections between this additional IP network 
and the interconnected networks shown in Fig. 3 could 
be through an intermediate network that did not use the 
IP network protocol, such as IPX network 160. In this 
case, node 140 and the additional nodes on the addi- 25 
tlonal IP network would not typically be discoverable by 
node 1 1 0 under prior art systems, even though the addi- 
tional network also uses the IP network and wouW be 
part of the interconnected networks shown in Rg. 2. 
This result occurs because the IP discover 1 03 compo- 30 
nent illustrated in Rg. 1 would not typically be able to 
discover nodes on an IP network If tfiat network was 
only reachable from node 110 through an intermediate 
network that did not use the IP network protocol, such 
as IPX network 160. 35 

Rg. 4 illustrates logical communication exchanges 
in which an IPX discover component discovers network 
information by requesting the information from network 
management information servx^es on target nodes. F»g. 
4 illustrates three components: IPX discover 102 which 40 
resides at node 1 (labeled node 1 10 in Fig. 2); NXIS 139 
which resk^es at node 3 (labeled node 130 in Fig. 2); 
and NXIS 410 which reskles at node 5 (labeled node 
209 in Fig. 2). Components NXIS 139 and NXIS 410 are 
each shown rrxjltiple times in Fig. 4. Ftg. 4 also illus- 45 
trates ten node-to-node oonrvnunications 422. 424. 426, 
42S. 430, 432. 434. 436. 438 and 440. In the illustrated 
example, the node*to-node communications occur over 
the IP network 150 (not shewn In Rg. 4), and occur over 
time such that the left-most comnrtunication 422 is the so 
earliest communication and the right-most communica- 
tion 440 is the latest conrYnunlcation. As illustrated In 
Fig. 4. additional communications can occur, and those 
skilled in the art will appreciate that numerous variations 
couU occur in the communication sequence, including 55 
the following: communications could occur with addi- 
tional NXIS components; NXIS components could 
reskie at nodes not part of network 150, such as node 
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224 in Rg. 2; conmumications couW occur other than 
over network 150. such as a temporary connection via 
modem or through a router connection to another net- 
work; communications could be synchronous such that 
the sender of a message waits until a reply is received 
before taking any other action; the comnuinications 
could occur with a network management information 
service other than an NXIS; etc. 

IPX discover 102 begins the <f scovery process by 
sending communfcation 422 to NXIS 139 which 
requests alt NXIS data which NXIS 139 can access. 
Since NXIS 139 resides on node 130 which is part of 
IPX network 160, illustrated in Fig. 2. NXIS 139 may 
have access to NXIS data which Includes IPX network 
information for network 160. This network irribrmation 
may include the following: node identification informa- 
tion for node 140 and node 224; network topology for 
network 160; network sendees offered for network 160, 
including NetWare service B 182; network 160 status 
information such as events or alarms, etc. At some time 
after receiving communication 422. NXIS 139 sends 
communfcation 424 to IPX discover 102 which Includes 
generation ID 3A and all NXIS data to which NXIS 139 
has access, (feneration ID 3A indicates the state of the 
NXIS data, such as a time-starrp or a database ID cor- 
responding to the state of a databasa Those skilled in 
the art will appredate that an NXIS nwy acquire NXIS 
data in numerous vrays, including searching an IPX net- 
work such as network 1 60 in response to a communica- 
tion, retrieving previously stored data from a datat>ase. 
requesting the data from anotiier node, etc. Some net- 
work services or nodes stae network information in 
databases which are accessible from nodes on the net- 
work, such as the NetWare Management System which 
stores IPX network information In the NetWare Manage- 
ment System datak^ase. 

At some time after receiving comnuinication 424, 
IPX discover 102 continues the discovery process by 
sending communication 426 to NXIS 410 which 
requests all NXIS data which NXIS 410 can aocesa 
Since NXtS 410 resides on node 209 which is part of 
IPX network 235. Ifluslrated in Rg. 2. NXIS 410 may 
have access to NXIS data whfoh Includes IPX network 
Infomiation tor network 235. This network information 
may include the followirYg: node identification infbrma* 
tion for node 232 and node 234; network topology for 
network 235; network services for network 235, includ- 
ing NetWare service C 236; rietwork 235 status informa- 
tion such as events or alarms, etc. 

Before receiving a response to communication 426, 
IPX discover 102 continues the dtscovery process by 
sending comnrtunication 428 to NXIS 139, which 
includes generation ID 3A and a request for all NXIS 
data wtiich has changed since the generation ID of the 
NXIS 1 39 data was 3A. As described earlfer. generation 
ID 3A indicates the state of the NXIS data that IPX dis- 
cover 102 had earlier received from NXIS 139 in com- 
munication 424. 
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At some time after receiving communication 428. 
NXIS 139 responds by sending communication 430 to 
IPX discover 102 which includes generation ID 3B and 
all NXIS data which has changed since the g»ieration 
ID of NXIS 139 data was 3A. Those skiBed In the art will 
appreciate that if no data has changed, communication 
430 would have no changed data In this situation, gen- 
eration ID 3B may be the same as generation ID 3A 
bK^ause the data has not changed, tor example a data- 
base ID that changes only when the data changes, or 
generation ID 3B may be different from generation ID 
3A, for example a generation ID thai is based upon the 
time that the communication is made. 

At some time after receiving conmunication 426 
and after NXIS 139 sends communication 430, NXIS 
410 responds to communication 426 l>y sending com- 
munication 432 to IPX discover 102. which includes 
generation ID 5A and aQ NXIS data to which NXIS 410 
has access. As described above. NXIS 410 will typically 
have access to IPX network information for network 
235. If NXIS 410 attenpts to send oomnnjnication 432 
very shortly after NXIS 139 sends communication 430. 
it is possible that a collision between the communica- 
tions could take place if IPX discover 102 can only 
receive one communication at a time, or if the communi- 
cation media, such as network 150. can only carry one 
communication at a time. If the communication mafia is 
network 150. then the network protocol, in this case IP. 
may coordinate the conmunications to ensure their 
recent. Alternately. IPX discover 102, the NXIS compo- 
nents 139 and 410. or some other conponent may act 
to ensure that the communications are received. Those 
skilled in the art vw'll appredate that it is also possible 
that a communication may be lost or contain an error 
which prevents the communication from being under- 
stood, which tmy cause the retransmittal of the commu- 
nication, or the loss of the communication if no 
retransmittal occurs. 

At some time after receiving communication 432. 
IPX discover 102 continues the discovery process by 
sending oommuntoation 434 to NXIS 410 which 
Includes generation ID 5A and a request for all NXIS 
data which has changed since the generation ID of the 
NXIS 410 data was 5A, At some time after receiving 
communication 434. NXIS 410 responds to communfca- 
Xion 434 by sending communication 436 to IPX discover 
102 which Includes generation ID 5A and no changed 
NXIS data. Communication 43S from NXIS 410 returns 
the same generation ID 5A as NXIS 410 received in 
communication 434 because no data has changed. 

At some time aftiar receiving communk:ation 436. 
IPX discover 102 continue the discovery process by 
sending communication 438 to NXIS 139. which 
requests all NXIS data whfch NXIS 139 can access. At 
some time after receiving communicatkw 438. NXIS 
139 responcfe to communication 438 by sending com- 
municatk>n 440 to IPX discover 1 02 which includes gen- 
eration ID 3C and at! NXIS data to whk:h NXIS 139 has 



access. Although an NXIS data was requested, those 
skilled in the art will appredate that if the NXIS data has 
not changed since the NXIS data send in comnwnica- 
tion 430 with generation ID 3B. the generation ID 3C 

5 sent in comnujnication 440 may be the same as gener- 
ation ID 3B. Additionally, those skilled in the art will 
a^Jredate that in alternate embodiments, requests for 
data other than the initial r^uest from a node, sudi as 
communication 438. could be restricted to chang«l 

10 information rather than aH information availat)le. 

Rg. 5 illustrates a more detailed block diagram of 
tfie IPX discover 102 main memory component that 
indudes the flow of information for the sut>components 
within the IPX discover 102 component. The IPX dis- 

75 cover 1 02 conponent is an exanple of a target network 
protocol discovery component, and some of the infor- 
mation in Fig. 5 is specific to IPX discovery In describ- 
ing Rg. 5, the prefened embodiment wfll be described in 
general terms, indicating when necessary which IPX- 

20 specific aspect of Fig. 5 is being descrtoed. 

Fig. 5 illusti-atos node 1 1 0. a user 501 at node 110. 
an appDcation program App A 506 that is executing 
somewhere outside of node 110. and a target network 
node with which node 110 can communicate and which 

25 has a network management information system (here 
NXIS Server Node 512. with an NXIS component). Dlus- 
trated node 1 10 components indude input device 1 1 1 . a 
target network protocol discovery conponent (here IPX 
dfecover 102), appfication program App B 508. tempo- 

30 rary storage 510. and display 112. While some node 
1 10 components illust-ated in Rg. 1 are not illustrated in 
Fig. 5. such as CPU 113. mass storage 114, internal 
bus 115 and main niemory 116. they are still present: 
application program App B 508 may be executing inside 

35 of main memory 1 1 6. the application's executable code 
may be stored on rrass storage 1 1 4, aixl the execution 
of App B 508 will require the use of CPU 1 13; tenporary 
storage 510 nr«y reside in n^in memory 1 16 or mass 
storage 114; IPX discover 102 is residing inside main 

40 memory 116; and information flow between corrpo- 
nents, illustrated by arrows indicating direction of infor-. 
mation flow, may occur on internal bus 1 15. Rg. 5 also 
illustrates the typical sutjcomponents of a target net- 
work protocol discovery component (here IPX discover 

45 102) induding scheduler 520. action queue and monitor 
522, discovery configuration database 524. irnporter 
526. dbiect nrtodeler and updater 528. parser/lranslator 
530. a discovery node object database (here SNM 
otject datateaea 534] and displayer 536. as well as 

so numerous information flows. Those skilled in the art will 
appredate that some or aH of the subcomponents 
shown could be joined together into a smaller number of 
subcomponents that combine the functionalities of the 
joined suboonrtponents. or that some or all of the sub- 

55 components shown couW be further divkJed into addi- 
tional subcomponents that split the functionalities of the 
divided subconrtponents. 

In the preferred embodiment of the inventkin. the 
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target network protocol discovery component (here IPX 
discGver 102) receives discovery information from a 
source external to its^. The discovery information 
directs the discovery component to dscovef the net- 
vwk information of a target network. The discovery 
information may contain several pieces of information, 
irtctuding the foltowing: the name of a target rxxJe with a 
network nranagement infonmation service (here NXIS 
Server Node Name); Node Connection Information, 
which is information that the discovery component will 
use to oommunkate with the target node; and Schedul- 
ing Information, which Is information that details how the 
discovering of the target network will take place. Those 
skilled in tfie art will appreciate that the discovery infor- 
mation could be transmitted to the discovery componer^ 
from a variety of sources external to rt. including from a 
user at the discovery node or at another node through 
an input device, from a application program executing at 
the cfiscovery node or at another node, from A combina- 
tk)n of external sources, etc. In the implemented 
embodiment, discovery information ts transmitted to the 
discovery component from a user. 

Node Cormeclion Information can include not only 
Infonnation such as the network address of the target 
node, which fadlttates contact and communication with 
the target node, but also irrformation such as pass- 
vwMds. Werrtification or keys that are necessary for the 
target node and its network management information 
system to respond to communk:ations from the discov- 
ery component. Scheduling Information can include 
information such as triggering information which indi- 
cates the conditk>ns under which the discovering 
actions of the discovery component will occur, such as 
at a specified future time, at periodic time intervals, 
upon discovery rx)de reboot, upon the discovery node 
object database reacHng a specified level of complete- 
ness, etc. In the implemented embodiment, only speci- 
fied time can be used as a triggering condition. 
Scheduling Information can also include lnforniatk>n 
XUaX describes the type of network information to dis- 
cover from the target networK such as only network 
topology Irrformation, aft network information available, 
or only network information ttiat has changed from a 
specified prevk>us state of network infbrmatkxi. In the 
tmplemertted embodiment, the type of network infomna- 
tion to discover is linrvted to all network information avail- 
able or only network information that has changed from 
a specified prevkxis state of network infornrtatk)n. TTK>se 
skilled in the art will appreciate that tine discovery infor- 
mation transmitted to the discovery component can 
vary, inducing a subset of the deserved information, or 
additional information not explicitiy described. 

In tine preferred embodiment of the invention, the 
discovery information sent to the discovery component 
is directed fo scheduler 520. If Schedufing Information is 
received t>y scheduler 520. scheduler 520 creates at 
least one discovery action that specifies hew the discov- 
ering of the target network will take place. All aeated 



dsoovery actions are sent to ttie action queue and mon- 
itor 522. The action queue and nxxiitor 522 stores dis- 
covery actions until an action is ready to be undertaken, 
at which time the action is sent to the importer 526. Typ- 

5 ically, the discovery action will have triggering informa- 
tion which is monitored by the action queue and nronitor 
522 and the satisfaction of the triggering information 
prompts the transmittal of the action to the inporter 526. 
If target node name Information or Node Connection 

ro Information is received by scheduler 520, scheduler 520 
sends this information to discovery configuration data- 
base 524. The discovery configuration database 524 
includes information which enables the dscovery com- 
ponent to accomplish its discovery of target network 

IS information, such as target node addresses, passwords, 
etc. as descn*bed earlier. 

Upon receipt of a discovery action, importer 526 
sends a request to discovery configuration database 
524 for Node Connection Information for the target node 

20 which corresponds to the received discovery action. 
The discovery configuration database 524 responds by 
sending the requested Node Connection Information to 
inporter 526. which will include the most recent previ- 
ously stored generation ID for the target node and target 

25 network if such a generation ID exists, trrporter 526 
then initiates a comnnunication with the network man- 
agement information service subcomponent on the 
specified target node (here NXIS sen/er node 512). Ttvs 
communication requests the target network information 

30 specified by the scheduling infomiation of tiie discovery 
action. The network management information sennce 
then sends this requested target network information 
(here NXIS information) to the importer 526. including in 
the sent informatfon a generation ID as described ear- 

35 lier t\aX coo'esponds to the state of the network infbrma- 
tioa Importer 526 then sends the received generation 
ID to the discovery configuration database 524 and 
sends the received target network information to tempo- 
rary storage 510. Finally, importer 526 sends a commu- 

40 nication to parser/translator 530 that indicates that 
network information has been received b/ tiie Importer 
526. Typically, this communication will indicate the toca- 
tion of the tenporarily stored target networi^ information. 
Those skiiled in the art will appreciate that it is pos- 

43 sible for communications to be lost or to contain an error 
which prevents the commurticaticMn from being under- 
stood, thai a reefer of a communfoatfon may be una- 
bte or unwilling to respor)d, and that the receiver of a 
request communication may not have access to the 

so information requested. If a response comnrtunicatbn is 
not received, then further actions which require informa- 
tion expected in the response will not be can-ied out until 
such information is av^lable. In addition, tfiose skilled in 
the art wni appreciate titat NXIS sen/er node 512 can be 

65 any target node with which node 1 10 cao'comnrwnicate. 
and which has a network management information 
service siibconponenl Typically, the discovery compo- 
nent win communicate with multiple target nodes as net- 
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work information is cfiscovered for multiple target 
networks; Ixit only one example target node is shown in 
Fig. 5 for purposes of illustrating the information ftow 
between a discovery component and a target noda 

At some point after receiving a communication from 
importer 526 that indicates network information has 
been received, parserAtranslator 530 sends a communi- 
cation to temporary storage 510 requesting the stored 
network information (here NXIS InfornBtion). After 
receiving the communication from importer 526. tenpo- 
rary storage 510 had stored the network intormation, 
and after receiving the request convnunicalion from 
parser/translator 530. temporary storage 51 0 sends the 
requested network information to parser/translator 530. 
Typicany, temporary storage 510 will remove the net- 
work information from storage after it is send to 
parser/translator 530. Those skilled in the art wUI appre- 
ciate that it is possible that importer 526 couW send mul- 
tiple request communications for network Information 
and receive multple response communications, from 
one or more target nodes, before the network informa- 
tion from the first request communication is sent to 
parserAranslator 530. To prevent the loss or destruction 
of received network information, it is possible for 
importer 526 to send network information received from 
each response communication to different temporary 
storage, or it is possifc»le for temporary storage 510 to 
receive all network information and maintain a corre- 
spondence between stored network information and 
received communication by importer 526. 

After receiving the stored network information from 
temporary storage 510, parser/translator 530 separates 
the network information into separate transactions. 
Each transaction conesponds to a single logical 
abstraction of network information from the target net- 
work. Each transaction may have multiple statements 
and may refer to multiple network entities on the target 
network. These entities can represent various network 
information, including the following: network nixies, 
components of network nodes, groups of nodes, net- 
work services, network event and alarm information, 
etc. For exanple, NXIS typically refers to Its network 
entities as objects, and assigns an NXIS object ID to 
each NXIS object A single IPX node may have multiple 
NXIS objects, such as for an Ethernet card, a print serv- 
ice, etc. In this case, the discovery component vwll typi- 
cally aggregate these nrwltiple NXIS objects into a 
single discovery node object that corresponds to the 
entire IPX node. Parser/translator 530 then sends multi- 
ple communications to object modeler and updater 528 
such that each communication includes a transactfon 
from the network information. 

Object modeler arxJ updater 528 receives commu- 
nications from parserAranslator 530. and models each 
network information transaction In software with a togi- 
cal object. In the example embodiment, object modeler 
and updater 528 models each NXIS transaction with a 
SunNet Manager (SNM) softwwe object. Software 
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objects are well known in the prior art and those skilled 
in the art will appredate that such objects typfoally are 
of a specff ic type that corresponds to a particular class 
type in a hierarchy of class types. Additionally, such 
5 ot)jects typically include data structures that hold infor- 
mation related to the object typicafly include methods 
that perform actions on the object, typically derive data 
structures and methods from the dass type to whkrfi 
they correspond, and typically inh^it some methods 
10 and some data structures from other class types that 
are above the particular dass type in the dass hierar- 
chy. Since the objects conespond to a particular dass 
type in a dass hierarchy, the object modeler and 
updater 528 will typically have access to at least one 
IS previously created dass hierarchy such that the dass 
types correspond to abstract network entities for the tar- 
get network. In the preferred embodiment the dass 
hierarchy will indude dass types which are specific to 
the network protocol of the target network and the type 
20 of the created abstract objed will indicate the network 
protocol of the network to which the object corresporxte. 
Those skilled in the art wiB appredate that the construc- 
tion of a class hierarchy used to model information can 
be a difficult tasK but that the use of such objects and 
25 o^ect-oriented programming techniques provkJes may 
benefits over more traditional programming technkjues. 
induding advantages such as data encapsulation, pdy- 
nrrarphism, and inheritance of methods and structure. In 
additioa those skilled in the art will appreciate that 
30 objed-oriented programming systems can vary in the 
representations and functionalities available in the sys- 
tem. 

The objed nxxjeler and updater 528 wfll maintain a 
correspondence between the created discovery node 

35 objeds and the one or more target network errtities to 
which the created object corresponds. To accomplish 
the modeling of the transadfon informatton, the object 
nrodeler and updater 528 will identify any network enti- 
ties which are referenced in a transaction. It wiU then 

40 determine if a discovery node object already exists 
which conesponds to the targeit network entities refer- 
enced in the transaction. If a discovery node object 
does exist the object modeler and updater 528 will 
send a communication which requests the otajed to the 

45 discovery node object database (here SNM oljjed data- 
base 534). If a discovery node object does not exist the 
objed modeler and updater 528 wHI aeate a new cGs- 
covery node object which corresponds to the network 
errtities in the current transaction, and will store the cor- 

50 respondence between the new object and the network 
errtities; The types of network entities and other transac- 
tion information wtti determine the type of discovery 
node object created. After the objed nwdeler and 
updater 528 has a discovery object that corresponds to 

55 the current transadfon. either a newly created bbject or 
an ot^ed received from the objed database in response 
to a request comnunication. the object modeler and 
updater 528 will update the object by storing the infbr- 
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mation from the transaction in the data structures of the 
object FtnaHy. the object rrxxleler and updater 528 will 
send a comnnunication to the object database which 
includes the updated object. 

K the object database (here SNM Object Database 
534) receives a request comnujnication from the object 
modeler and updater 528 for a particular object, the 
object database will respond with a commmication to 
the object modeler and updater 528 that includes the 
requested object. When the object database receives a 
communication from the object nrxxieler ad updater 528 
that includes an object, the object database will store 
the object, regardless of whether the object is new or an 
updated version of a previously stored object tf any 
changes occur to the data stored in the object database, 
the object database will ser^ a communication to the 
displayer 536 which includes the changes in the data. 

If the displayer 536 receives a communication from 
the object database that includes changes in object 
data, the displayer 536 will send a communication to the 
display 112 that includes updated display information 
that reflects the updated state of the object database. 
Those skilled in the art will appreciate that the displayer 
may actually communicate with an intermediate compo- 
nent such as an executing application program in the 
main menvjry 116, and this intermediate component 
may communicate with the display 112. In addition, 
those skilled in the art will appreciate that wt^le it is not 
illustrated in Rg. 5, a user may interact with the dis- 
player 536 or an intermediate conrponent to modify the 
display information, or to make changes to the discov- 
ery component subcomponents such as the object 
database, discovery configuration database 524. action 
queue and nrionltor 522. etc. In the example embodi- 
ment of Fig. 1. the SunNet Manager Console 101 can 
act as an intermediate component and facilitate the 
management of network information by a user who 
invokes network management functionality. As well as 
displaying network information, an intermecfiate compo- 
nent such as the SunNet Manager Console nr^y allow 
the user to send communications to contactable nodes 
and after the status of nodes, including the network 
services offered by the nodes. Such a intermediate 
component ooiild also act as an intermediary between 
the user and the discovery component for the purposes 
of entering discovery information ihai the discovery 
componerrt will use to discover network information for 
target networks. Those skilled in the art will appreciate 
that displayer 536 or an intermediate oorrponent could 
conrvrtunicate with a display and a user on another node 
instead of. or in addrtkxi to. node 110. 

The following references to Figs. 6-1 1 will desaibe 
the processing f tow for the preferred embodiment using 
as an example an IPX discovery component on an IP 
node that.is discovering network information from a tar- 
get IPX network. TTiose skilled in the art will appreciate 
that the processing f bw is not limited to the discovery of 
network information tor IPX networks, nor is the 



processing f k}w limited to discovery by a discovery node 
on an IP network. 

Rg. 6 illustrates the general ficm diagram for the 
Discover IPX Network Information from IP Network 

5 Routine 610. The 610 routine begins at step 620 by 
checking a queue of scheduled discovery actions. Dis- 
covery actions specify information about how to dis- 
cover target network information, including when the 
action should t>e executed After checking the queue, a 

10 determination is made at step 630 whether any discov- 
ery actk)ns are currently in the queue If there are dis- 
covery actions in the queue, then the routine proceeds 
to determine in step 640 if any of the actions in the 
queue are ready to be executed, tf soi the routine pro- 
is ceeds to the Execute Scheduled Discovery Action Sub- 
routine in step 650, which is descrbed further with 
respect to Rg. 8. and executes the subroutine. After 
execution of the siA>routine in step 650, the routine pro- 
ceeds to return to step 620 to check the discovery 

20 action queue. 

tf none of the actions in the queue are ready to k>e 
executed at step 640, the routine proceeds to step 660 
to determine if there are additional discovery actions to 
schedule. Those skilled in the art will apprecate that 

25 these additional discovery actions could be new 
actions, or reschedules of previously created actions. If 
there are not additional discovery actions to schedule, 
the routine proceeds to return to step 620 to check the 
discovery actk>n queue, tf there are additional discovery 

30 actions to schedule, the routine proceeds to the Sched- 
ule Discovery Action Subroutine in step 670. which is 
descrit>ed further with respect to Fig. 7. and executes 
the subroutine. After execution of the subroutine in step 
670. the routine proceeds to return to step 620 to check 

35 the discovery action queua If there are not any actions 
in the queue in step 630. then a determination is made 
at step 680 whether there are any additior^ discovery 
actions to be scheduled and added to the action queue, 
tf there are not any discovery actions to schedule, then 

40 the routine exits at step 690. Those skilled in the art will 
appreciate that the 610 routine can later be reinvoked 
on a periodic t>asis or if there are adcfitional discovery 
actbns to schedule or execute, tf there are discovery 
actk)ns to schedule in step 680. the routine proceeds to 

45 the Schedule Discovery Action Subroutine in step 670 
and executes the subroutine, and then rejoins the flow 
of the routine wNch is descrbed above. 

Referring rtow to Rg. 7, the gweral flow diagram for 
the Schedule Discovery Action Subroutine 670 is 

so descrbed. The scheduling of a discovery action begins 
at step 710 by kfentifying a target node firom which to 
dsoover network irtfbrmation (or the target network. In 
the preferred ent>odiment, the target node will typically 
be a network node that sufsports a netwo^ manage- 

55 nwTt infomrwtion service, such as NetWare Manage- 
ment System Export Import Service (NXIS). The 
subroutine proceeds to step 720 where node connec- 
tion infonnation for the target node is specified. This 
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node connection inforniation typically includes the net- 
work address of the target node, or information which 
allows the identification of the target node suc^ that the 
discovery node can initiate convnunication with the tar- 
get node. Those stdlled in the art will appreciate ttiat if 5 
discovery actions have already been conducted for this 
target node and the node connection information for the 
target node is already stored and accessible to the dis- 
covery node, then it may not be necessary to provide 
node connection information tor the scheduling of a dis- jp 
covery aOion. The node connection information also 
typically includes information that allows the sharing of 
data between the discovery node and the target node 
and its network management information service after 
communication is estat>lished. Th& irrfbrmation can 75 
include information such as passwofds, computer port 
numbers, public or private encryption keys, etc. 

After specifying node connection information, the 
subroutine proceeds to step 730 where action schedul* 
ing infbnnation is specified. The action scheduling infor- so 
mation typically includes a description of the type of 
network information desired and triggering conditions 
which indicate when to execute the discovery action. 
The networit information desired nnay include all net- 
work information available, only network information 
that has changed since some previous state of network 
information, only network information on network serv- 
ices available, etc. The triggering conditions can indi- 
cate a variety of conditions including the execution of 
the discovery action immediately or as soon as possi- 
ble, the execution of the discovery action at some future 
specified time or at specified intervals, the executbn of 
the cfiscovery action when some physical condition 
occurs such as when the load on the CPU drops below 
a certain amount or when a database or file system has 
a certain anDount of space available, etc. Those skilled 
in the art will appreciate that alternate embodiments 
may offer different options for specifying action schedul- 
ing informatioa including variations on the types of net- 
work information desired. 

After specifying action scheduling Infomnatton, the 
subroutine proceeds to step 740 where a discovery 
action is created. The discovery action will typically 
have access to its scheduling information, as well as the 
name or identifier of the target node which corresponds 
to the action. Those skilled in the art wilt appreciate that 
a discovery action could be innplemented in many ways. 
irKluding a data structure, a textual entry in a fist, a soft- 
ware object etc. After the discovery action is created, 
the subroutine proceeds to step 750 where tiie node 
connection information and node nan>e for the target 
node are stored in the discovery configuration data- 
base. Once stored, this information will be accessit>le by 
other subcomponents. After the target node information 
is stored, the subroutine proceeds to step 760 wtiere 
the newly created discovery action is placed on the 
Action Queue and Monitor. Discovery actions remain on 
the queue untO they are ready to be executed. Tho&e 



skilled in the art will appreciate that tiie action queue ad 
monitor couM be implemented in a variety of ways, 
including elements in a list ti^t are periodically polled, 
software objects tiiat nx)nitor their own conditions and 
notify another subcomponent when they are ready to t>e 
executed, etc. TTiose skilled in the art will also appreci- 
ate that some steps in the subroutine are ind^>endent 
of other steps, and ti^e order of execution can be varied. 
For example, step 750 could occur before step 730. or 
after 760. Additionally, if a parallel processing system is 
in use, step 750 could occur in parallel with steps 740 or 
760. After the new discovery action is placed on tine 
action queue, the subroutine proceeds to step 770 
where a determination is made whether tiiere are more 
actions to schedule tor the target node identified in step 
710. If there are n>ore actions to schedule, then the sub- 
routine returns to specifying action scheduling informa- 
tion in step 730, and rejoins the f fow of the subroutine 
which is described earlier. If there are not more actions 
to schedule, then the subroutine proceeds to step 7B0. 
which ends the subroutine and returns to the flow from 
w^ich the subroutine was exectited. 

Ref en-ing now to Rg. 8, the general flow diagram for 
the Execute Scheduled Discovery Action Subroutine 
650 is described The execution of a discovery action 
begins at step 810 where a scheduled discovery action 
that is ready to be executed is removed from the Action 
Queue and Monitor. After the action is removed, the 
subroutine proceeds to step 820 where the connection 
information for the target node is retrieved from the dis- 
covery configuration databasa The subroutine then 
proceeds to step 830, where the discovery node uses 
the target node connection information to begin a com- 
munication to the target node. In the preferr^ embodi- 
ment, this is accomplished by opening a two-way 
connection between ti^e discovery node and the target 
node. The subroutine next determines in step 840 the 
amount of infornnation desired by the discovery node for 
this discovery action. It the anwunt of Informatton is not 
all of tiie information available from the target node, but 
ratiier only the changed Information from some previous 
state of the network trrformation. then the subroutine 
proceeds to step 860 where the most recent generation 
ID for network information from this target node is 
reti'ieved from the discovery configuration datatsase. 
After retrieving the generation ID, the sutxoutine pro- 
ceeds to step 870 where the discovery node makes a 
request to tiio target node for network Information of the 
type specified, particulariy that which has changed 
since the state of target network information corre- 
sponded to the retrieved generation ID. The subroutine 
then proceeds to step 880 where the discovery node 
sends the communication, and doses its side of the 
connection. If, on the other hand, it was determined in 
step 840 tinat alt available network information was 
desired, then the sii)routine woJd proceed td step 850. 
where the discovery node requests from the target node 
aB network Information of the type specified, includtr^ 
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the possbiiity of all information available. The subrou- 
tine then proceeds to step 880 where the dscovery 
node sends the communication, and closes its side of 
the connection. 

Those skilled in the art wID appreciate that there are 
various ways that the desired network information could 
be obtain^ other than requesting it from a network 
management information service such as NXIS at the 
target node, including the following: the discovery node 
could retrieve previously stored network protocol dis- 
covery mechanisms that are specific to the target net- 
work, and execute these mechanisms at the target node 
to discover the desired network Information directly from 
the target network; the discovery node could access a 
database of stored target network information that was 
present on the target node or a node on the target net- 
work: the discovery node could execute a function at the 
target node that would request the desired target net- 
work information from arwther node on the target net- 
work; etc. After the communication has t>een sent and 
the discovery rxxfe side of the connection has been 
closed in step 880. the subroutine proceeds to the 
Receive Requested Data from Node Subroutine in step 
890 and executes the subroutine, to be desaibed below 
with respect to Rg. 9. arxi then rejoins the flow of the 
cun-ent subroutine. After executing the subroutine in 
step 890. the current subroutine proceeds to step 895. 
which ends the current subroutine and returns to the 
fk3w from which the current subroutine was executed. 

Referring now to Fig. 9. the general flow diagram for 
the Receive Requested Data from Node Subroutine 890 
Is described. The receipt of requested target network 
information deOa begins at step 910 where the discovery 
node receives a communication from the target node 
that includes the requested network information and a 
generation ID that corresponds to this informalran. The 
subroutine proceeds to step 915 where the received 
network information is stored in temporary storage at 
the discovery node. The subroutine then proceeds to 
step 920 where the generation ID that was received is 
stored whh other information related to the target node 
and target network in the discovery configuration data- 
base. This generation ID will be used later if changes 
are requested that have occurred since this state of the 
target network infonnation. The subroutine next pro- 
ceeds to the Read a Transaction from Stored Data Sub- 
routine in step 925, which is described farther with 
respect to Fig. 10, and executes the subroutine. This 
subroutine will read a transaction from the stored target 
network information. After execution of the sii>routine in 
step 925. the cunent subroutine proceeds to the Model 
Transaction Information with SunNet Manager Objects 
Subroutine in step 930, which is described further with 
respect to Rg. 11. and executes the subroutirte. This 
subroutine will model the transaction infomnation into a 
representation of target network information that is used 
by the discovery node. 

After execution of the sibroutlne in step 930, the 



current subroutine proceeds to step 935 and deter- 
mines whether there are more transactions in the stored 
data. If so. the current sii^routine returns to step 925 to 
read the next transaction, and rejoins the flow of the cur- 

5 rent subroutine as described above. If not the current 
subroutine proceeds to step 940 and determines if new 
target network infonnation has been added to the dis- 
covery node's object representation of accessisle net- 
work information. In the preferred embodimem. if new 

10 objects of a specified type have been created, the sut>- 
routlne proceeds to step 945 to update the display to 
show tfiese new objects, tn the example embodiment, 
SNM tHJS objects .components objects and view objects 
are objects of the specified type. The subroutine then 

15 proceeds to step 950 to update the display to reflect 
new information that has changed in previously existing 
otjects. If no new objects of the specified object types 
were created, the current subroutine proceeds instead 
from step 940 directi/ to step 950 to update the display 

so to reflect new information. Those skilled in the art will 
appreciate that in other embodiments, different types of 
objects will be present at tiie top level of the display, and 
thus the creation of these object types will prompt the 
display to t>e upxJated. It is also possible that the cfisplay 

25 will never be automatically updated, and will only 
change if a user requests the display of new informa- 
tion. After the display is updated, the cun-ent subroutine 
proceeds to step 955, which ends tiie sulwoutine and 
returns to tine f tow from which the subroutine was exe- 

30 cuted. 

Refening rww to Fig. 10. the general flow diagram 
for the Read a Transaction from Stored Data Subroutine 
925 is desaibed The process of reading a transaction 
begins at step 1010 where the first statement in the 

35 Stored target network information is read. The current 
subroutine proceeds to step 1020 where an empty list is 
aeated and designated to be the cun-ent transaction 
list. Proceeding to step 1030. the most recently read 
statement of target network information is entered onto 

40 ihe current transaction list. The current sut)routine then 
proceeds to step 1040 and determines if ttie most 
recentiy read statement was tiie end of the current 
transaction in the network information. H it was not the 
current subroutine proceeds to step 1050 to read the 

45 next statement In the target network infornudion, and 
then returns to step 1030 and rejoins the ftow of the cur- 
rent subroutine as descr(t}ed above. If the most recently 
read statement was the end of the current transaction, 
the currerrt subroutine proceeds to step 1060 where all 

so of the statements on the current transaction fist are 
grouped together and the group is desi^^ted to be the 
current transaction. The sulxoutine then proceeds to 
step 1 070 to remove the statements in the cun-ent trans- 
action from the stored target network inf^nr^tion from 

65 whidi they were read. Those skilled in the art will appre- 
date tfiat other equivalent processes can be used to 
read the statements of a specific transaction and group 
them together. After removing the &taten>ents in step 
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1070. the current subroutine proceeds to step 1080. 
which ends the subroutine and returns to the flow from 
which the subroutine was executed. 

Referring now to Fig. 1 1 . the general flow diagram 
for the Model Transaction Information with SunNet Man- 5 
ager Objects Subroutine 930 is desaibed The process 
of nxxJefing transaction information begins at step 1110 
where a pra^ously created object model is retrieved 
that represents the possible types of objects which can 
correspond to the network irrformation in the transac- to 
tion. In the preferred embodiment, as described above, 
a dass hierarchy which is specific to the network proto- 
col of the target network will be used as a model. In the 
example embodiment the objects that are created will 
be SNM objects. The current subroutine then proceeds is 
to step 1115 where a determination is made whether 
any target network entities are referenced in the current 
transaction. In the example embodiment NXIS ot>ject 
IDs will be sought in NXIS network information from the 
target node. Each target network entity couW be treated so 
as a separate target network node, or multiple network 
entities couW exist for a single target network node. H 
there are no network entities referenced, the subroutine 
will proceed to step 1165, which ends the subroutine 
and returns to the flow from which the subroutine was 25 
executed. If there are network entities referenced in the 
current transaction, however, the current subroutine will 
proceed to step 1120 to retrieve the first reference to a 
target network entity from the information in the cunent 
transaction. The cun-ent subroutine will then proceed to so 
step 1125 to deterntine If the retrieved target network 
entity corresponds to a existing discovery node object. 

If it does not correspond in step 1125. the current 
subroutine will proceed to step 1145 to create a new 
discovery node software object that con-esponds to the as 
target network ^ity or entities and the other target net- 
wortc information in the current transaction. The new 
ol^ect will be of a type specified by the object model 
previously retrieved in step 1110. After the object is cre- 
ated, the con-espondence between the newly created 4o 
discovery node object and the target network entities in 
the current transaction wilt be stored in an object map- 
ping datat>ase in step 1 150. The current subroutine will 
proceed to step 11 35 to determine if there are more ref- 
erences to target network entities in the current transac- 45 
tion information. If there are more references, the 
current subroutine will proceed to step 1 1 40 to retrieve 
the next reference to a target nelvvork object from the 
information in the cunrent transadioa and then proceed 
to step 1 125 and rejoin the f tow of the current subtou- so 
tine as described abova If the retrieved target network 
entity does correspond to an existing discovery node 
object in step 1125. the current subroutine proceeds to 
step 1 130 and retrieves the eadsting object from the dis' 
covery node object database. The current sulxoutine ss 
then proceeds to step 1135, and rejoins the ftow of the 
current subroutine as described abova 

If there are not more references to target network 



objects in step 1 135, the current subroutine will proceed 
to step 1 1 55 to update the retrieved and aeated discov- 
ery node objects with network Information in the current 
transaction. Proceeding to step 1 160 after the discovery 
node objects are updated, the updated discovery node 
objects wilt be stored in the discovery node object data- 
base, which will be the SNM object database in the 
example embodiment Finally, after the objects are 
stored in step 1 150, the current subroutine proceeds to 
step 1 165. which ends the subroutine and returns to the 
flow from which the subroutine was executed 

There has thus Ijeen descn*bed a metiiod, appara- 
tus and computer system tor discovering the nodes and 
other network Information of a target computer network, 
from a discovery node that is not part of that netwvork, 
partk;ularly wtien the discovery node uses a different 
network protocol than the target network. The discovery 
of the target network information involves one or more 
target nodes that have access to network information 
about the target network, and with whom the discovery 
node can communk:ate. Although the present invention 
has been described in terms of preferred, implemented 
and example embodiments, this is by way of illustration 
only. Accordin^y. the scope of the present invention 
should be detemiined in light of the claims which follow. 

Claims 

1. A computernmplemented method for discovering 
informatkin ^ut a first computer network having a 
plurality of nodes, from a device remote from said 
first network, wherein said first network uses a first 
network protocol and said remote device uses a 
second network protocol different from said first 
network protocol, said method comprising the steps 
of: 

a) identifying a node with which the remote 
device can communicale wherein said identi- 
fied node has access to information about the 
first network; 

b) receiving information about the first netivork 
from the Wentified node wherein said received 
first network infamation includes node connec- 
tion information and node type irrformation for a 
plurality of first network nodes; 

c) retrieving an object model including object 
type definitions wherein sakl type definitions 
are renwte device representations of node 
types for nodes using the first network protocol; 

d) creating a plurality of objects representing 
the received first network information such that 
each object has a type specified by the 
retrieved ot^ect model; and 

e) using the created objects to tden^ f irst net- 
work nodes accessible from the remote device. 

:. The method of claim 1 wherein: 
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the remote device and flie identified node are 
nodes on a second computer network; 
commurdcalion between the kJentffied node 
and the remote device uses the second net- 
wofic protocol: and 

the created otsjects are used to identify first net* 
work nodes accessible from the second net- 
work. 

The method of claim 1 wherein the received first 
network information includes node topology and 
network service information tor the first network. 

The method of daim 1 wherein each aeated object 
is a logical representation of node connection and 
type information for a plurality of first network 
nodes. 

The method of claim 1 wherein the remote device 
contacts the identified node and specifies a functton 
to be executed by a first network node, and wherein 
the received first network information is in response 
to said executed function. 

The method of claim 1 wherein the identified node 
is a first network node and the received first net- 
work infamation is in response to a first communi- 
catbn from the remote desoce to the kfentif ied node 
requesting that the identified node transnwl first net- 
work information to the remote device. 

The nwthod of claim 6. comprising the further steps 

of: 

f) receiving additional first network infonmation 
from the Wentified node to identify changes 
from previously received first network informa- 
tion; and 

g) modifying the aeated objects to reflect klen- 
tif ied changes. 

The method of daim 7 wherein the additional infor- 
mation is received in response to a second oomrrui- 
nication from the renxrte device to the identified 
node specifying a first time and a second time later 
than said fffst time* and wherein sakl second com- 
munication requests that the identified node trans- 
mit infomiation at a time later than said second 
tinne. said transmitted inlonratk}n to tndude differ- 
ences b fret network information between said first 
and second tinr>e. 

The method of daim 7 wherein the additional infor- 
matkm is received in response to a second oonmi- 
nication transntitted from the rwnote dence to the 
identified node such that said transmittal requires 
the satisfaction of at least one condition prevkxisly 
specif ied at the remote device. 



10. The method of claim 7 v/herdn the addrtiorwl infor- 
mation indudes network status information in the 
form of network event information and node event 
information. 

5 

11. The method of daim 7 wherein the first network 
protocol is IPX network protocol ad the identified 
node provides first network irrformation by using 
IPX network functionality to coflect network infor- 

70 mation and transmit the collected information to 
renxrte devfees. 

12. The method of daim 7 wherein the second netvwrk 
protocol is a IP network protocol, and the first net- 

75 work protocol does not have the capatxiity to 
resporvl to tP network protocol requests for network 
information. 

13. The method of daim 7 wherein the first network is 
20 managed from the remote device by using objects 

representing received first network irrformation to 
provide funtionality to second network nodes, said 
functionanty including first network services and 
connectivity to first network nodes. 

25 

U. An apparatus for discovering information about a 
remote first corrputer network having a plurality of 
nodes, wherein said first network uses a first net- 
work protocol and sakj apparatus uses a second 
30 network protocol different from said first network 
protocol, said apparatus comprteing: 

an input component that receives Wentif ication 
of a node sudi that the apparatus can commu- 
35 nicate witii said identified node, and scheduOng 

information specifying first network information 
to be discovered; 

a scheduler that creates at least one discovery 
action corresponding to the Wentified node and 
40 received scheduling information; 

an action executer that executes a created dis- 
covery actton In accordance with the schedul- 
ing information corresporxfing thereto such that 
the identified node corresponding to the dis- 
45 covery action is contacted using the second 

network protocol and a transmittal of the sped- 
f ied first network information to the apparatus is 
arranged: 

an importer that receives first r>etwork infbrma- 
50 tion; ard 

an object modeler that models received first 
notvyork informatfon and uses modeled infor- 
mation to determine nodes accessfole to the 
apparatus. ^ 

55 / 

15. The cpparatus of daim 14 wher^n the received 
scheduling information further specifies conditions 
under wtBch a corresponding discovery action is to 
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be executed and whereffi the apparatus further, 
conrprises: 

an action morBtor that determines when speci- 
fied conditions of the scheduling information 
corresponding to the created discovery action 
are satisfied and notifiies the action executer of 
said determination. 

16. The apparatus of claim 14 wherein anangement of 
a transmittal of ^ecified first network information 
during execution of a discovery action is accom- 
plished by requesting that the identtf led node corre- 
sponding to the discovery action transmit the 
spedfied fnst network information. 

17. The apparatus of claim 14 wherein arrangemeni of 
a transmittal of spedfied first network infonnation 
during execution of a discovery action is accom- 
plished t>y executing a function specific to the first so 
network protocol on the Identified node correspond- 
ing to the discovery action. 

18. The apparatus of claim 14 wherein modeling 
received first network Wbrmation involves creating 25 
a plurality of objects such that each object has a 
type specified by a stored object model and said 
created objects are logical representations of 
received informatk?n for a plurality of first network 
nodes, and wherein sakJ object model includes 3o 
object type definitions which represent first network 
infonnation and are specific to the first network pro- 
tocol. 

19. The apparatus of daim 18 wheren the apparatus 35 
further comprises: 

an object presenter that uses created objects 
to determine nodes accessible from the appa- 
ratus. 



20. A comput©- system for discovering information 
about a remote first computer network having a plu- 
rality of nodes, wherein said first network uses a 
fifBt network protocol and saU computer system 
uses a seoorx) network protocol different from sakl 
first network protocol, said computer system com- 
prising: 

an input component that receives kSentiftcation 

of a node such that the computer system can 

commurticate with sakl tientified node, and 

scheduling information specifying first network 

informatk)n to be discovered; 

a scheduler that aeates at least one discovery 

action corresponding to the identified node and 

received scheduling infomiation; 

an action executer that executes a created dis- 
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covery action in accordance with the schedid- 
ing information corresponding thereto such that 
the ktentified node conesponding to the (£s- 
ccvery action is contacted using the second 
network protocol and a transmittal of the speci- 
fied first network information to the computer 
system is arranged; 

an importer that receives first network infonna- 
tion induding node connection informatkwi and 
node type infamation kx a plurality of first net- 
work nodes; and 

an object modeler that models received first 
network infornnation by creating a plurality of 
objects that represent the received first net- 
work information, and uses created otsjects to 
Identify nodes accessible to the computer sys- 
tem. 

21. The computer system of daim 20 wherein: 

the computer system is a node on a second 
computer network; 

communication between the identified node 
and the computer system uses the second net- 
work protocol; 

each created object is a logical representation 

of node connectton arid type information for a 

plurality of first network nodes; and 

the logical representations are nodes identified 

to be accessible from the second computer 

network. 

22. The conrpjter system of claim 21 wherein: 

the first network protocol is IPX; 
the second network protocol is IP; 
the first network does not have the capability to 
respond to IP network protocol requests for first 
network information; and 
the Identified node provides first network infor- 
mation by using IPX network functionality to 
collect network Information and transmit the 
collected informatkjn to remote devices. 

23. An artide of nvinufacture comprising a computer- 
readable medium ar>d a computer program embod- 
ied ttierein, for discovering information about a 
remote first computer network having a plurality of 
nodes, wherwn said first network uses a first net- 
work protocol and said computer program uses a 
second network protocol different from said first 
network protocol, sakJ conrputer program compris- 
ing: 

an input functionality that receives identification 
of a node such that the computer prbgram can 
communicate with said kjerrttfied node, and 
scheduling information specifying first network 
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information to be discovered and conditions 
under which the discovery of first netwaK infor- 
mation is to be accomplished: 
a schedule functionality that creates at least 
one discovery action corresponding to the 5 
identified node and received scheduling infor- 
mation; 

an execute functionality that executes a cre- 
ated discovery action in accordance with the 
scheduling information con-esponding tiiereto io 
such that the identified node corresponding to 
the discovery action is contacted using the sec- 
ond network protocol and a transmittal of the 
specified first network ffiformation to the com- 
puter program is arranged; rs 
an import functionality that receives first net- 
work information; and 

an object modeling functionality that models 
received first network information and uses 
modeled information to determine no6es 20 
acceesUe to the computer program. 

24. The article of manufacture of claim 23 wherein 
anangement of a transnrvttal of spedfied first net- 
work information during execution of a discovery 2S 
action is accomplished by requesting that the iden- 
tffied node corresporxling to the discovery action 
transmit the specified first network information. 

25. The artid e of manufacture of claim 23 wherein: 30 

modeling of received first network information 
involves creating a plurality of objects such that 
each created object has a type specified in a 
stored object nradel; 35 
^e object model includes object type defini- 
tions specific to the first network protocol; 
the created objects represent received first net- 
work information; and 

each aeated otsject is a logical representation 4o 
of received first network information for a plu- 
rality of first network nodes. 
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